Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP12。

知識庫解決了「該怎麼判斷」，但現場工作常常還需要「動手做點什麼」。

連線到裝置、下幾個特定指令、重啟某個服務、確認狀態。這類操作如果每次都讓 AI 臨場現拼指令，風險其實不小：一個打錯的參數，可能就是一次不小心的裝置異常。

所以我們把這類重複性的裝置操作，包裝成一顆顆獨立的 skill，例如「遠端服務控制」、「韌體更新後的狀態驗證」、「裝置設定檔同步」。每一顆 skill 都把連線方式、允許的參數範圍、輸出格式與安全界線寫在同一份文件裡。

# skill: service-control

## Inputs
- 目標裝置連線資訊
- 動作：start / stop / restart / status

## Outputs
- 執行前後的服務狀態（不是只回報指令有沒有跑完）

## Safety
- restart 前一律先回報目前狀態，等待確認才執行
- 不記錄裝置的內部序號或帳密

skill 文件刻意把「能做什麼」和「不能做什麼」寫在同一份裡，讓一項能力的邊界一眼就看得見。

這裡有個容易被忽略但很關鍵的設計：skill 的責任是提供「一項能力」，不是扮演一個什麼都會的萬能代理人。 這讓 AI 在處理任務時，可以只載入真正需要的那一顆 skill，而不是每次都把整套裝置操作規則一次讀完——上下文乾淨，出錯的機率也跟著降低。

這加起來其實就一句話：skill 是一項能力，不是萬能代理人；每次只載入當下需要的那一個。

能力包好了，接下來要解決的是：這些指令實際上要怎麼被穩定地執行，而不是每次都由 AI 臨場拼湊？

下一篇來聊腳本扮演的角色。